Most multiprocessor systems have two or more central processing units that are not completely identical, but instead have a degree of individual special features and functions. The tighter coupling between the multiprocessors integrated on a single chip allows for a more efficient passing of data than for similar multiprocessors implemented at the board level. Each central processing unit may have a different memory map, different peripheral set and perhaps even a different instruction set. In applications that have very distinct boundaries, such as a wireless telephone, this method of extracting optimum performance is crucial.
In this conventional embedded multiprocessor system, as a general rule, while the multiple central processing units are integrated, each is generally running its own program. In a symmetric embedded multiprocessor system, by contrast, multiple central processing units are running the same program, albeit different threads of that same program. The threads could be run on any one of the central processing units at any given time, as opposed to the conventional embedded multiprocessor systems in which each central processing unit will normally be running its own program.
As a result, the coupling of hardware resources such as memory and peripherals are not simply tighter in the symmetric embedded multiprocessor case, but these resources are accessed differently and are of an architectural structure fundamentally different from the conventional embedded multiprocessor case. Currently, embedded central processing units share a great deal of hardware, but such hardware relies strongly on the software to provide protection from access request collisions. In the symmetric case, all hardware is not only shared, but the hardware architecture is such that it is invisible to the software and requires only very minor support in the operating system. This support differs from the conventional case only in the boot routines and in the manner in which a thread is launched versus a single central processing unit case. Consider the effect this has on software debugging and the software debugging tools.
In the case of conventional multiprocessors, debugging works well when the programs are running independently. By contrast this debugging would be complicated when the processing involves interaction operations such as use of a shared variable or shared resources. In these situations one central processing unit would have no information what the other central processing unit was accessing or changing. In a symmetric multiprocessor all central processing unit operations are interaction operations and there would be obvious difficulties.
As a result there is a need for direct testing of the software thread interactions. This testing becomes a critical part of the verification on the part of the user that the program is working with these thread interactions fully active.
Though the software debugging tools use the same test access port controller that the hardware debuggers use, the test access port controller is used to facilitate the scanning in of special debug instructions directly into the central processing unit during the interval between the times the central processing unit is running a real user program. These instructions set breakpoints, watch points on variables and other parameters of importance. They are inserted and acknowledged behind the scenes of the program being debugged. Thus the user is never required to program a debug instruction. These instructions are inserted by the debug tools.
The starting point would be a single central processing unit case, and taking how the tools work in the single central processing unit case, and extending it to a symmetric multiprocessor case. A great deal of engineering has already been done on debug methods for conventional non-symmetric multiprocessors. For symmetric multiprocessors, however, there is an additional requirement to ensure variables do not change without the user being aware of those changes since the all data and status information is shared.